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Abstract 

The use of IP filtering as a means of improving system security is well established. Although there are 
limitations at what can be achieved doing relatively low-level filtering, IP level filtering has proved 
to be efficient and effective. 

q , In the design of a security policy there is always a trade-off between usability and security. Re- 

stricting access means that legitimate use of the network is prevented; allowing access means illegit- 
imate use may be allowed. Static access list make finding a balance particularly stark — we pay the 
■ price of decreased security 100% of the time even if the benefit of increased usability is only gained 

CT) \ 1% of the time. 

Dynamic access lists would allow the rules to change for short periods of time, and to allow local 
changes by non-experts. The network administrator can set basic security guide-lines which allow 
certain basic services only. All other services are restricted, but users are able to request temporary 
exceptions in order to allow additional access to the network. These exceptions are granted depending 
on the privileges of the user. 

This paper covers the following topics: (1) basic introduction to TCP/IP filtering; (2) semantics 
for dynamic access lists and; (3) a proposed protocol for allowing dynamic access; and (4) a method 
for representing access lists so that dynamic update and look-up can be done efficiently. 
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^ ! 1 Introduction 

The use of IP filtering as a means of improving system security is well established. Although there are 
limitations at what can be achieved doing relatively low-level filtering, IP level filtering has proved to be 
efficient and effective [10]. 

The access lists that are used to implement IP filtering contain rules that specify which packets should 
be allowed to pass through the firewall. Access lists may last for several years and so may be changed 
from time to time (rules may be added or deleted, old rules changed, or the order of the rules change). 
Nevertheless, an access list is relatively static. 

The problem with a static access list is that the level of security is relatively static. This becomes 
increasingly a problem as the range and type of network travel increases. 

Striking the right balance between usability and security is one of the key issues in network design. 
Using static access lists makes choices in finding a balance particularly stark. Restricting access means 
that legitimate use of the network is prevented; allowing access means illegitimate use may be allowed. 
A user may only need certain accesses for 15 minutes a day (1% of the time), but when they need the 
access they really need the access. On the other hand, keeping access available 99% of the time when 
no benefit accrues seems too liberal. One should only take a risk when some benefit may result. As an 
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analogy, after I do a large grocery shopping I might leave my car door and front door wide open while I 
trudge back and forth carrying grocery packets because it makes the job easier and faster, but I certainly 
don't leave the doors open all the time. 

The idea behind dynamic access lists is to allow the rules to change for short periods of time, and to 
allow local changes by non-experts. The network administrator can set basic security guide-lines which 
allow certain basic services only. All other services are restricted. However, users are able to request 
temporary exceptions in order to allow additional access to the network. These exceptions are granted, 
depending on the privileges of the user. Dynamic access lists have been used in CISCO routers for some 
time [4]. What is being proposed here though is a much more general framework for making access lists 
dynamic. 

Structure of the paper 

Section 2 gives a basic introduction to TCP/IP filtering and explains some of the relevant issues and 
techniques. Section 3 surveys possible semantics for dynamic access lists and proposes one which is 
argued makes intuitive sense and is sound. Section 4 presents the outline of a proposed protocol for 
allowing dynamic access. Section 5 describes a method for representing access lists so that dynamic 
update and look-up can be done efficiently. Section 6 proposes some experiments to be performed. 

2 Background 

2.1 Fire walling 

Security can be provided at a number of different levels and in different places. For example, we may 
secure individual computers or we may secure networks. There are different advantages and disadvan- 
tages of these different approaches - see [10] for a discussion. I argue that the advantage of dynamic 
access lists is that it allows more flexibility, allowing defence in depth. In addition, we are able to take 
into account different needs of different user classes, rather than just physical location. 

Firewalling can be done at different levels. For example, proxies use application-layer information 
in controlling network connections. Because they can use high-level information, they are able to make 
good quality decisions. However, this imposes extra costs. 

IP-level filtering is much simpler and therefore cheaper, although this limits the intelligence of the 
filtering. The use of user-classes in the dynamic approach may increase the intelligence of the approach. 

Even though the IP filtering is relatively efficient, the cost of filtering may still be a significant bottle- 
neck [2]. Significant work has gone into improving the performance of IP filtering [6, 7, 9, 12]. The fact 
that filtering is a bottle-neck means that dynamic filtering must not introduce significant extra costs. 

2.2 IP filtering and Rule sets 

TCP/IP filtering is a slightly misleading terminology since in fact it means filtering using information 
found in the internet, network and transport layer headers (depending on the protocol suite). Typically 
the information that can be found in the these headers is: 

• source and target addresses of the packet; 

• the protocol of the packet (e.g. udp, tcp, icmp, . . . ); 

• ports; 

• certain flags (for example, a tcp packet contains flags indicating status for connection control). 

See a standard reference for more details (e.g. [13]). 

This paper considers TCP/IP packets in particular, but the methods generalise to similar protocols. 



Filter rules come in several formats; typically these are proprietary formats. While the expressiveness 
and syntax of the formats differ, the following generic description gives a good feeling for what such rules 
sets look like. A rule set consists of a list of rules of the form if (condition) then action, 
where the action is either accept or reject. 

Example: A rule in a rule list for a Cisco router [5] might say something like: 

access-list 101 permit tcp 20.9.17.8 0.0.0.0 

121.11. 127 .20 0.0.0.0 

range 2 3 2 7 

This says that any TCP protocol packet coming from IP address 20.9.17.8 destined for IP address 121.11. 
127.20 is to be accepted provided the destination port address is in the range 23 ... 27. ■ 

Masking: A rule can specify a range of addresses by using masking for both the source and destination 
addresses (in the above, the masks were 0.0.0.0, which means no masking). An address is actually a 32 
bit number, which is convenient for humans to express in the quad notation (four numbers each in the 
range . . . 255). A mask is expressed similarly. If a "1" appears in the mask, then the value of the 
corresponding bit in the address is ignored in matching. In the above example, since the masks are all 
the addresses must match exactly. But, if we had 20.9.17.8 0.0.0.255 as the source address, 
then any address with 20.9.17 as a prefix would match. If 20. 9. 17. 8 0.0.0.1 were the source, 
then any even address with 20.9.17 as a prefix would match. 

Matching a list of rules: The rules are searched one by one to see whether the condition matches the 
incoming packet: if it does, the packet is accepted or rejected depending on the action (which will either 
be accept or reject); if the condition does not match the rule, the search continues with the following 
rules. If none of the rules matches, the packet is rejected. 

Since the rules are checked in order, the order in which they are specified is critical. Changing 
the order of the rules could result in some packets that were previously rejected being accepted (and/or 
vice-versa). 

This paper uses CISCO access-list format as the basis specifying the rule set, but the methods pro- 
posed generalise to other formats. 

3 The Semantics of Exceptions 

The complication in defining the semantics arises from the importance of the order of an access list to the 
semantics of the list. This section explains why this is a problem, presents alternate semantics, proposing 
one of them as possible semantics of exceptions. 

3.1 The naive semantics 

The naive semantics would be to consider the exceptions as an extension of the base list. In this view, the 
exceptions are temporarily pre-pended or appended to the base list. While this is simple to implement 
and in some cases could have an understandable effect, it is highly problematic. 

Suppose the extensions are pre-pended to the base list. Then, because ordering is critical, all exten- 
sions will over-ride all base rules: there is no way of ensuring that certain rules are always obeyed. 

Conversely, if the rules are appended then an exception can never over-ride any of the base rules: in 
effect, an exception is only an exception to the default reject rule. This is more desirable and useful than 
prepending, but it reduces the flexibility of a security policy, and would be likely to lead to a situation 
where the base rules are more liberal than necessary in order to allow the exceptions to have some use. 

More sophisticated direct modification of the access lists seems unlikely given the high-level of 
expertise required to make changes and the complexity of the interplay between rules. Inserting dynamic 



rules somewhere in the middle of the list may give more flexibility but will not be flexible enough, and 
be too difficult to understand the effect. 

3.2 A tree-based approach 

A more sophisticated policy is to have multiple lists, instead of having one access list. These lists could 
be ordered by priority, and for each list, rejects could be mandatory or flexible. The highest priority list 
or the base list would be the main list which the network administrator sets up. In practice, the lower- 
priority lists would be of a fairly simple structure: a number of accepts followed by some mandatory and 
flexible rejects. 

In the tree-based approach, in order to decide whether a packet should be filtered, the lists are 
searched in order. If, while searching a list, an accept rule is matched, the packet is accepted; if a 
mandatory reject rule is matched the packet is rejected; otherwise if a flexible reject is matched the next 
list of rules in priority is searched. 

Dynamic access requests can be effected by pre-pending the access rule to one of the lower-level 
priority lists. Different security policies can be implemented by allowing different classes of user to 
pre-pend to different lists (the higher the priority of the list to which the user can prepend, the more 
privileged the user), and by the choice of the reject rules in the lower-priority lists. 

This policy has intuitive appeal, and could be implemented relatively efficiently. However, it has a 
very serious problem in that it alters the semantics of rule lists significantly; in particular, in the interplay 
between the ordering of the rules within a list and the ordering of lists. The simple example lists shown 
in Figure 1 illustrates the problem. 

In Figure 1, we have two access lists, with List being of higher priority than List 1. Condition Cij 
gives the matching condition for a packet for rule j in List i. Suppose we wish to know whether to accept 
or reject packet p and assume that packet p matches conditions co,i, co,2 and c^o but does not match the 
other conditions. By the semantics just explained, p will be accepted; first List is searched and since 
the first rule that matches p is rule 1, a flexible reject, we carry on searching List 2, and since the first 
rule that matches in List 1 is rule 0, we accept. 

However, suppose that we delete rule 1 of List 0. Now, the packet p would be rejected since the first 
rule that p matches against will be rule 2, a mandatory delete. Thus, we get a situation where deleting a 
reject rule can increase the probability of a packet being rejected 1 . 



Rule# 


ListO 


List 1 





accept co,o 


accept cifi 


1 


reject flexible co,i 


reject flexible ci ; i 


2 


reject mandatory cq,2 


reject flexible ci ; 2 



Figure 1: Sample lists 

The underlying problem that this example illustrates is that the order of rules in a list is very important 
for the semantics. Implementing this 'tree' semantics confuses issues because ordering is used both to 
establish priority between lists, and to implement the standard semantics of rule lists. It makes backwards 
compatibility with existing rule lists difficult. 

3.3 Principles of semantics 

The issues raised sections 3. 1 and 3.2 lead to the following principles relating to the semantics of dynamic 
lists: 

1. The semantics should support flexible policies. 

'And, thinking of the flexible reject as a conditional accept doesn't help either - opposite monotonicity constraint violations 
can be shown. 
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2. The behaviour of dynamic changes and the interaction between the dynamic rules and the base 
rules must be clearly understandable to the person maintaining the base list, without knowledge of 
what the dynamic rules are. 

3. It must be possible for a user to request a dynamic access rule without knowledge of the base rules 
or other dynamic rules. 

Of course, the firewall may not allow such a request if it conflicts with security policy, but a non- 
expert user (or a simple agent on behalf of a user) should be able to make the requests. 

4. The base and dynamic rules must be well-behaved. Adding an accept rule should increase the 
chance of packets being accepted; adding a reject rule (flexible or mandatory) should increase the 
chance of packets being rejected. (And conversely for deleting rules). 

5. Ideally, we should be able to use existing rule sets without much change. 
Efficiency is obviously also an important question, addressed in Section 5. 

3.4 The multiple list priority-based approach 

The multiple list priority-based approach also uses multiple rule lists, ordered by priority. Again, for 
each list the reject rules are split into mandatory or flexible. 
The security policy is succinctly expressed as: 

A packet p is accepted by the firewall if it is accepted by rule list j and there exists no 
mandatory reject rule in lists ... j — 1 that match it. 

Again, dynamic changes can be effected by allowing users to prepend accept rules to one of the lower- 
priority lists, depending on the users' privilege level. 

These semantics are far clearer than the semantics in Section 3.2 and more closely meet the conditions 
of Section 3.3. 

Implementation of this approach is not as simple as that of Section 3.2, but the implementation 
technique described in Section 5 would allow an efficient implementation. 

The disadvantage of this approach is that it would require the duplication of rules. For example 
suppose that we wish to have as a default or base rule that access to machine x is not allowed, but that 
users in class 1 to i should be allowed to over-ride this rule, and users in class i + 1, . . . should not. 
Implementing this requires flexible reject rules in the base list and in lists 1 ... i — 1, and a mandatory 
reject rule in list i. This proliferation of rules will make administration much more difficult and increase 
the chance of errors. 

3.5 The group-based approach 

This paper proposes the group-based approach as the semantic basis for supporting dynamic access lists. 

In the group-based approach (GBA), there is one base access list and n exception lists (numbered 
. . . n — 1, assuming n user groups). The base access list is the existing access list, except that each 
reject rule has a set of associated group identifiers ... n — 1. These group identifiers indicate which 
groups are able over-ride the reject rule. Groups may be contained within other groups. The semantics 
of the GBA are: 

A packet p is accepted by the firewall if 

1 . It is accepted by the base list; or 

2. It is accepted by some exception list j where all reject rules in the base list are labelled 
by j or by a super-group of j. 



Thus, if a rule in the base list is not labelled with any group identifier then it cannot be over-ridden. 
I argue that this semantics meets the conditions of Section 3.3. 

1. Flexible policies are supported since by assigning several priority levels for reject rules, the net- 
work administrator can allow different classes of user different abilities to request dynamic access. 

2. Interaction between the base list and the exceptions is clear since (a) the normal semantics of the 
access lists is disturbed very little; and (b) the use of group membership for the reject rules makes 
it clear what different classes of users can and can't do. 

3. Users do not need to know what the base rules are in making a request for dynamic access. 

4. The monotonicity constraints are met. 

5. Existing rule sets can be used as-is. Dynamic access can then be implemented over time by as- 
signing group membership. There is no need for radical change. 

The efficient implementation of the GBA is discussed in Section 5. 
3.5.1 Example 

Here we look at a simple example shown in Figure 2. The format used is similar to the CISCO ac- 
cess list format; the number at the beginning of each line is just used for reference in this explanation. 
The example gives rules for a subnet 128.128.128. The machine 128.128.128.15 is a special server; 
the other machines in the range 128.128.128.0 to 128.128.128.127 are for staff; machines in the range 
128.128.128.128 to 128.128.128.255 are for students. In this example, group is the staff group, group 
1 the student group, and group 2 the all group, which contains both groups and 1. 

1: accept tcp 0.0.0.0 255.255.255.255 128.128.128.15 0.0.0.0 eq 88 

2: deny tcp 0.0.0.0 2 55.255.255.255 128.128.128.15 0.0.0.0 

3: accept tcp 0.0.0.0 255.255.255.255 12 8.128.128.0 0.0.0.255 eq 88 

4: accept tcp 0.0.0.0 255.255.255.255 12 8.128.128.0 0.0.0.255 ge 32000 

5: deny tcp 0.0.0.0 2 55.255.255.255 128.128.128.0 0.0.0.255 range 87 

6: deny tcp 0.0.0.0 255.255.255.255 12 8.128.128.0 0.0.0.127 ge 89 

7: deny tcp 0.0.0.0 2 55.255.255.255 128.128.128.128 0.0.0.127 It 16000 

8: deny 1 tcp 0.0.0.0 2 55.255.255.255 128.128.128.128 0.0.0.127 ge 16000 

9: deny 2 everything 

Figure 2: Simple example dynamic base list 

Rule says that we accept tcp connections to the machine 15 on port 88. Rule 1 says that we deny 
(with no exceptions allowed) all tcp connections to machine 15 on any port. Since rules are examined in 
order the combined effect of these two rules is that tcp connections to machine 15 are accepted on port 
88 only. Rules 3 and 4 say that on all machines on the subnet we accept tcp connections on port 88 and 
ports in the range 32000 to 65535. (Since rules 1 and 2 come before rules 3 and 4, rules 3 and 4 will not 
affect machine 15 since we have denied access to ports other than port 88 on machine 15) Rule 5 denies 
tcp connections to any machine on the subnet to any port in the range through 87 and no derogation 
from this rule is allowed. 

Rule 6 says that we deny tcp connections to any of the staff machines (range 128.128.128.0 to 
128.128.128.127) on any port numbered 89 or higher. However, we allow members of the staff group to 
request exceptions to this rule. Note there is some overlap between this rule and previous rules: in this 
overlap the previous rules take priority because they come first. 

Rule 7 says that we deny tcp connections to any student machines on any port numbered less than 
16000. (Since rule 3 comes first, connections to port 88 are still allowed). Rule 8 says that we deny any 



connections to student machines on ports with a number greater than or equal to 16000. Members of 
the student group are allowed to request exceptions to this rule. (Connections to ports > 32000 are still 
allowed since rule 4 comes first.) 

Finally, rule 9 denies any other packets. However, any member of either the staff or student group 
can ask for exceptions. 

Note, that without any exceptions, the semantics of the access list is unchanged from the standard 
semantics. 

Now, let's look at the effect of exceptions. Suppose we have the following exception lists: 

Exception list 

0.0 accept tcp 0.0.0.0 255.255.255.255 12 8.128.128.1 0.0.0.0 eq 100 
0.1 accept tcp 0.0.0.0 255.255.255.255 12 8.128.128.1 0.0.0.0 range 90 
0.2 accept tcp 0.0.0.0 255.255.255.255 12 8.128.128.129 0.0.0.0 eq 16000 



Exception list 1 

1.0 accept tcp 0.0.0.0 255.255.255.255 12 8.128.128.2 0.0.0.0 eq 100 

1.1 accept tcp 0.0.0.0 255.255.255.255 12 8.128.128.129 0.0.0.0 eq 16000 

1.2 accept icmp 0.0.0.0 255.255.255.255 128.128.128.129 0.0.0.0 

Exception list 2 

2.0 accept tcp 0.0.0.0 255.255.255.255 128.128.128.130 0.0.0.0 eq 16000 

2.1 accept icmp 0.0.0.0 255.255.255.255 128.128.128.130 0.0.0.0 

Exception 0.0 allows tcp connections to be made to port 100 on machine 1. Any packets that come 
to this port will be accepted because they are accepted by exception list and the only rules that deny 
access to this port are rules 6 and 9. Both allow exceptions to be requested by members of group and 
so this exception can be honoured. 

Exception 0.1 purports to allow tcp exceptions to ports through 90 on machine 1. However, packets 
that come to ports through 87 will not be enabled by this exception since they are rejected by rule 5 
which does not allow derogations. TCP packets going to port 88 were in any event allowed by rule 3. 
Packets going to port 89 and 90 will be allowed by the exception since the rules that deny access to this 
port (6 and 9) allow exceptions to be made by members of group 0. 

Exception 0.2 purports to allow packets going to port 16000 on machine 129. However, rule 8, which 
applies here, can only be derogated from by members of the student group. 

Exception 1.0 purports to allow tcp connections to port 100 on machine 2. This has no effect, how- 
ever, since rule 6 denies access to this port and as the rule only allows derogations by staff member, only 
exceptions in exception list can over-ride it. 

Exception 1.1 does have effect though since it allows access to port 16000 on machine 129 and the 
relevant deny rule (8) has is labelled group 1 (and hence can be over-ridden in exception list 1). Similarly, 
exception 1.2 will allow icmp packets to reach machine 129 since the relevant deny rule (9) is labelled 2 
(the all group). 

Exception 2.0 purports to allow tcp connections to port 16000 on machine 130. However, as rule 8 
denies such connections and is labelled group 1 , exceptions that over-ride rule 8 must be in exception list 
1. However, exception 2.1 does allow icmp access to machine 130 since rule 9 is labelled 2. 



A priority based approach 

Note that if the groups are set up in a strictly hierarchical way, the group-based approach corresponds to 
a priority-based one. 

3.6 Should accept rules have priorities? 

Should accepts also have priorities and allow exceptional denies? This has the appeal of symmetry, but 
while this would allow extra functionality it is not clear that this would be useful and would certainly 
lead to undesirable problems of interactions between users. 



4 Protocol for dynamic update 



This section proposes a protocol for dynamic access list by specifying how communication between user 
processes and the firewall takes place. At this stage this is only a preliminary proposal since we need to 
get experience with more substantial prototype systems before finalising details. When a user 2 wishes 
to ask for dynamic access, it sends a request to the firewall. The firewall logs and validates the request, 
checks to see whether the request can be fulfilled and then responds to the user. This section describes 
this communication in more detail. How the firewall maintains the requests, performs updates, and does 
look-ups is covered in Section 5. 

4.1 Request for dynamic access 

A request for dynamic access takes four steps: 

• The user sends a request to the firewall asking for access; 

• The firewall sends back a response indicating to what degree the access can be given; 

• The user then sends a message to confirm whether it wants the access given. 

• If the firewall receives the confirmation within a given time interval, the exception is made; other- 
wise the exception is not made. 

First step - asking for access: The user sends a packet to the firewall asking for access to be given. 
The packet is sent as a UDP packet to a well-known port on the firewall, and contains the following 
information: 

• Originating IP address and UDP port (part of the IP/UDP headers). 

• User identification: this must enable the firewall to identify the group of the user. 

• Access required: this would be a list of accept rules indicating what access is wanted. 

• Expiry time: The user specifies for how long the exception should be enabled. 

Firewall response: When the firewall receives the request packet, it validates the user and determines 
the group membership. It then examines the update request. 

• If the update request can be met completely (i.e. all the requests asked for do not clash with a deny 
rule which cannot be derogated from by members of the user's group), then the firewall sends back 
to the user an allow full message with a unique dynamic update ID. 

At the same time, the firewall inserts the update in a queue of pending exceptions. 

• If the update request cannot be met at all (i.e. all the updates clash with a deny rule which cannot 
be derogated from by the user under GBA) a reject message is sent back to the user. 

• In general, the update firewall may be able to honour some of the dynamic update requests but not 
others (see the discussion on Exception 1.0 in Section 3.5.1). In this case the firewall sends back 
to the user an allow partial message with a unique dynamic update ID, as well as a description of 
those requests that can be honoured. 

At the same time, the firewall inserts the update in a queue of pending exceptions. 
2 Here, user will probably be some process acting on behalf of a human, rather than a human. 
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There are number of open implementation decisions: should the firewall accept update changes from 
outside or only from inside? How are users identified? It may be the userid of a user that the firewall 
knows about (it could have its own database or use NIS), or it could be a capability-based system. The 
identification could be authenticated by digital signature. This and other messages in the exchange may 
or may not be encrypted. 

What information is returned with the allow partial message is another implementation decision. In 
the approach proposed in Section 5 a full description will be returned. However, there might be reason 
just responding with a reject or allow. 

Confirmation by user: If the user receives a reject message, then it has to reconsider what it wants. If 
the user receives an allow message, it decides whether it wishes to use the update, and if so it sends back 
to the firewall a confirm message together with the unique ID. This step ensures that the firewall only 
implements changes that the user really wants. It also helps reduce the chance of spoofing attacks on the 
firewall. 

Firewall implements the exception: When the firewall receives the confirm request it removes the 
update request from the pending queue, and adds it to the appropriate exception list, timestamping the 
update as it does so. 

Periodically, the update queue is scanned and old requests are purged. 

4.2 Undoing a an update 

Since the access list is supposed to be dynamic, it must be possible to undo the change. This can be done 
easily by deleting the exception. There are two proposed mechanisms for this: 

• The user sends a delete request to the firewall with the unique ID of the update. The firewall 
authenticates the request and then deletes the update. 

• The firewall periodically checks the exceptions and when an exception has expired (the time since 
it was added to the exception list longer than the expiry time associated with the exception), the 
exception is deleted. 

Other mechanisms are possible. For example, the firewall could monitor the traffic associated with the 
exception and when it detects that there has been no traffic for some period then the exception is deleted. 
However, this is likely to be considerably more complex and heavy-weight than the proposed method 
here. 

4.3 Renewing an exception: 

A user may wish to extend the life-time of an existing exception. This can be done by sending the renew 
message to the firewall with user ID and expiry time. 

5 An implementation mechanism for dynamic lists 

The following principles guide the implementation mechanism proposed here. The principles are listed 
in descending order of importance: 

• The cost of doing look-up for packets that are not affected by dynamic update rules should not be 
adversely affected; 

• For each update rule, at least 10 additional packets will be affected by the update rule; therefore, 
the cost of look-up for exceptional packets must be small; 



• The cost of updating and undoing updates must be small. 

This section is structured as follows: Section 5.1 discusses the basic method for representing access 
lists; Section 5.2 presents the method of efficiently performing updates to the access list and performing 
lookup; and Section 5.3 shows how undoing updates can be performed. 

5.1 Basic Representation of Access Lists 

The chosen method for representing an access list is as a single (rather large) boolean expression. As 
described in Section 2 each rule in the access list is a condition on the bits in the packet header, and hence 
if we represent each bit in the packet header with a boolean variable, we can represent the condition as a 
boolean expression over these variables. Given a packet to filter, we give the variables in the expression 
their values as given by the bits in the packet header. The packet is accepted exactly when the boolean 
expression evaluates to true. 

Constructing a boolean expression for each rule: The boolean expression for each rule is constructed 
from its constituent components. For example, if the protocol is represented in 8 bits in the packet header, 
then we introduce 8 boolean variables po, . . . ,P7. We can then represent the condition that the packet 
must be a packet of protocol type protocol 1 by the boolean condition: 

P7P6P5P4P3P2P1P0 
where juxtaposition is used for conjunction and primes represent negation. 

Constructing a boolean expression for the list: An entire access list can be thought of as a big if- 

then-else statement, and so once we have converted each individual rule into an a boolean expression it 
is a straight-forward matter to convert the entire list into a boolean expression. 
For example, suppose we have the list: 

1: accept tcp 0.0.0.0 255.255.255.255 12 8.128.128.15 0.0.0.0 eq 88 

2: deny tcp 0.0.0.0 255.255.255.255 128.128.128.15 0.0.0.0 

3: accept tcp 0.0.0.0 255.255.255.255 12 8.128.128.0 0.0.0.255 eq 88 

Suppose the boolean expressions associated with rules 1, 2, and 3 are 0i,02, and ^3 respectively. 
Then the entire list can be represented by the expression: (pi V — >02 A 4>3- 

The detailed mechanics of this translation are beyond the scope of this paper. The important point is 
that these boolean expressions can be efficiently represented using binary decision diagrams [3]. See [8, 
7] for a detailed explanation of how this is done. The work of Attar [1] and Sinnappan [11] shows that this 
method of representing access lists is a very compact representation and that look-up can be performed 
competitively (with respect to other methods) in both software and hardware. What particularly made 
this representation scheme appear promising for dynamic access lists were the results that (a) the cost of 
lookup is robust in the number of access rules and (b) the variation on look-up cost is very low. 

5.2 Implementing updates and exceptions 
5.2.1 Representation of base list and exceptions 

The previous section showed that any set of access list conditions can be represented as a boolean ex- 
pression. This section describes how the base list and exceptions can be represented under GBA. 
The following notation is used: 

• (pB- The boolean expression representing the base access list. 

If we are not considering exceptions, then a packet is accepted by the list if under the interpretation 
of variables given by the bits in the packet 4>b is true. 



• <f>A' The boolean expression representing the access list together with exceptions. Where there are 
no exceptions, 4>a = 4>b- 

• 0j : for each group i, the disjunction of the deny rules that are not labelled with i or a supergroup 
of i. So, if we instantiate the variables in (f>i with values from the bits in a packet header, we find 
out whether an exception in list i can over-ride reject rules in the base list in order to allow this 
packet. 

• ej-. the expression representing exception list j. 

Under the GBA semantics given in Section 3.5 (on page 3.5) the boolean expression that represents a 
prioritised access list and n exception lists is: 

4>A = <\>B V (V£^& A a) (1) 
The firewall keeps the following information: 

• 4>b, the representation of the base list; 

• For each update request u, 4> u , the boolean expression representing the exception, the ID of the 
request, expiry time and the group of the originator of the request; 

The update requests are stored in a manner so that they can efficiently be accessed by ID number, 
by expiry time, and by group number. 

• For each i, <f>i\ 

• For each i, e^; 

5.2.2 Making an update 

This section describes in detail the behaviour of the firewall in response to the protocol described in 
Section 4. 

Update request received: When a new update u arrives with originator priority j, the following is 
done: 

• 4> u is computed, the boolean expression representing u; 

• 4> u A -i<pj is computed: This represents which exceptions that a user of this level of priority can be 
granted. 

- If 4> u A -<(f)j = f , then none of the exceptions can be granted; 

- If <p u A -1(f) j = 4> u , then all the exceptions can be granted; 

- Otherwise only some of the requests can be granted. 

• If none of the exceptions can be granted, the request is deleted and the user is sent a reject message. 

• Otherwise the user is sent an allow full or allow partial message, and the request is put on the 
pending list. 

In the case of an allow partial message various types of information can be returned to the user. 
The most useful would be tabular representation of 4> u A ->4>j. An algorithm for presenting this is 
described in [7]. 



Confirm message received: When the firewall receives a confirm message for update u, the following 
happens: 

• The update is stored with the associated information in an easily accessible form as described 
above; 

• €j is updated: €j <— 6j V 4>u A ~>^>j', 

• 4>a is recomputed according to Equation 1. 

5.3 Undoing updates 

In principle, undoing an exception is straight-forward. When an exception of priority j is undone, 

• The exception is removed from the list of active exceptions; 

• €j is recomputed; 

• <pA is recomputed according to Equation 1 . 

Undoing is likely to be more expensive than creating the exceptions because there is much more com- 
putation to be done. When we make an exception, there are relatively few changes to be made, whereas 
with undoing there will be many more. A number of factors will, hopefully, reduce the significance of 
this: 

• Undoing is unlikely to be time-critical (i.e. if it takes a few seconds extra to undo the exception, 
there will be no serious consequences). Thus, we only need to consider the cost in terms of the load 
it places on the server. And since it is not critical undoing can be done as a low-priority process. 

• BDD packages use caching of results to get performance improvement. Undoing may be able to 
exploit this. 

However, the cost of undoing is likely to be the critical factor in the performance of this approach. 

6 Conclusion and Proposed experiments 

This report has proposed the use of dynamic access lists for IP filtering, arguing that the benefits of 
dynamic lists are increased flexibility and security. 

A semantics for dynamic access lists was proposed and motivated, as well as a protocol for interaction 
between the users and the firewall. 

The previous section described a mechanism for implementing dynamic access lists. 

Proposed experiments 

The key question in evaluating the proposed protocol and implementation is time performance, and to a 
lesser extent memory (though previous work has shown that memory is unlikely to be a constraint). 
In terms of performance there are two criteria by which this must be measured: 

• Increased latency experienced by users; 

• Extra work-load placed on the firewall 
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Previous work indicates that dynamic access lists should not lead to increased look-up time as the 
boolean representation is a robust one. Hence, from a user perspective, latency only increases when 
an update request is being made, and not when packets are being filtered. Since update requests are 
relatively rare, and given the wide variance of time in internet access, for the purpose of this work, a time 
of 5s cost from start of request to request being granted was set upon. This would be indistinguishable 
from other network delays to the average user. 

The firewall may have to deal with requests from many users. If the cost of making and undoing 
updates is significant then the performance of the firewall as a filter may degrade. Thus, we are interested 
in the overhead from the firewall's point of view. This then will be the central thrust of the experiments. 

Acknowledgements: Pekka Pihlajasaari made a number of valuable comments on a draft of this ma- 
terial, including the suggestion of generalising from a priority-based to a group-based scheme. 



References 

[1] A. Attar. Using binary decision diagrams to improve packet filtering performance. MSc Research 
Report (forthcoming), School of Computer Science, University of the Witwatersrand, 2001. 

[2] S. M. Ballew. Managing IP Networks with Cisco routers. O'Reilly, October 1997. 

[3] R.E. Bryant. Symbolic Boolean Manipulation with Ordered Binary-Decision Diagrams. ACM 
Computing Surveys, 24(3):293-318, September 1992. 

[4] Cisco Systems Inc. Cisco IOS Lock and Key Security. CISCO White Paper, 1996. 

[5] Cisco Systems Inc. Configuring IP Systems. Published at the Cisco web site, 1997. http:// 
www.cisco.com /univercd /cc /td /doc /product /software. 

[6] P. Gupta and M. McKeown. Packet classification on multiple fields. In Proceedings of the SIG- 
COMM '99, pages 147-160. ACM, 1999. 

[7] S. Hazelhurst, A. Attar, and R. Sinnappan. Algorithms for improving the dependability of firewall 
and filter rule lists. In Workshop on the Dependability of IP Applications Platforms and Networks, 
pages 576-585, New York, June 2000. IEEE Computer Society Press. In Proceedings of the Inter- 
national Conference on Dependable Systems and Networks. 

[8] S. Hazelhurst, A. Fatti, and A. Henwood. Binary Decision Diagram Representations of Firewall 
and Router Access Lists. Technical Report TR-Wits-CS-1998-3, Department of Computer Science, 
University of the Witwatersrand, October 1998. Proceedings of SAICSIT '98. 

[9] J. McHenry, P. Dowd, T. Carrozzi, F. Pellegrino, and W. Cocks. An FPGA-based coprocessor 
for ATM firewalls. In Proceedings of the IEEE Symposium on FPGAs for Custom Computing 
Machines, pages 30-39, April 1997. 

[10] C.L. Schuba and E.H. Spafford. A Reference Model for Firewall Technology. In Proceedings of 
the Thirteenth Annual Computer Security Applications Conference, December 1997. 

[11] R. Sinnappan. A Reconfigurable Approach to TCP/IP Packet Filtering. MSc Research Report 
(forthcoming), School of Computer Science, University of the Witwatersrand, 2001. 

[12] V. Srinivasan. Fast address lookups using controlled prefix expansion. ACM Transactions on 
Computer Systems, 17(1): 1^4-0, February 1999. 

[13] K. Washburn and J. Evans. TCP/IP: running a successful network. Addison-Wesley, Harlow, 1996. 



1 o 



